Combinatorial Approach to Prevent SQL Injection Attack
Neha Tiwari1,
Praful Daharwal2, Samrat Kavishwar2
1Assistant Professor,
Dept. of Information Technology, Nagpur Institute of Technology, Nagpur
2Assistant Professor,
Dept. of Mechanical Engineering, Nagpur Institute of Technology, Nagpur
*Corresponding Author:
ABSTRACT:
As more businesses and
organizations provide online services, the number of web sites or applications which are linked to a
database has increased greatly. Often the data held in such databases is
confidential or private – and possibly of great interest to a hacker,
disgruntled employee, or criminal group. While the database and the server
holding it may have been secured, the design of the web interface is often
overlooked and could allow unauthorized users access to the database. SQL
injection, the use of database commands in the SQL language where user input is
expected, remains a top threat. It was the 3rd listed error in the January 2009
“CWE/SANS Top 25 Most Dangerous Programming Errors”[a]
and has been the mechanism for a number of prevalent attacks. For example,
through most of 2008 there were ongoing, indiscriminate and widespread attacks
on vulnerable web sites, which added a link to a malicious file (usually
JavaScript) that most web site visitors would unintentionally run on loading
the page. This then caused the visitor’s computer to be infected with malware.
Even well-known and widely trusted web sites were affected by this problem.
This document will illustrate some of the main techniques used in SQL
injection, then describe methods that can reduce the
effectiveness of such attacks. In addition to usual standard IT best practice,
such as logging and regular and prompt patching, the majority of SQL injection
vulnerabilities can be moderated through careful and robust programming. It is
hoped that the information provided here will highlight the seriousness of
leaving this type of flaw unaddressed and promote the improved design of
database-linked Internet resources.
KEY WORDS:
INTRODUCTION:
Structured Query
Language (SQL) is used to interrogate and manage relational databases such as
Microsoft SQL Server, MySQL, Oracle, Postgress SQL and Sybase. While there is an ANSI/ISO
standard for SQL defining elements such as keywords and grammar, most of the
major implementations do not employ the full SQL standard and add
implementation-specific procedural extensions. For this reason much SQL code is
written for a certain target platform and is unlikely to transfer easily to
another.
SQL injection occurs when an SQL instruction
is entered in a field of an application or web page that a user can change in
an attempt for it to be passed to and executed by the back-end database.
There are a number of forms of SQL injection,
which can be broadly separated into input validation circumvention and blind
SQL injection. While some attacks are directed at a weakness in the database
software, the majority of attacks seen use a flaw in the interface to the
database to (without permission) access, add, or modify data, or to execute a
command on the server itself. Clearly there can be serious consequences when a
malicious SQL injection attack succeeds, affecting the confidentiality,
integrity and availability of the data and services it supports.
Problem Definition:
As more businesses and organizations provide
online services, the number of web sites or applications which are linked to a
database has increased greatly. Often the data held in such databases is
confidential or private – and possibly of great interest to a hacker,
disgruntled employee, or criminal group. While the database and the server
holding it may have been secured, the design of the web interface is often
overlooked and could allow unauthorized users access to the database. SQL
injection, the use of database commands in the SQL language where user input is
expected, remains a top threat. It was the 3rd listed error in the January 2009
“CWE/SANS Top 25 Most Dangerous Programming Errors”[a]
and has been the mechanism for a number of prevalent attacks. For example,
through most of 2008 there were ongoing, indiscriminate and widespread attacks
on vulnerable web sites, which added a link to a malicious file (usually
JavaScript) that most web site visitors would unintentionally run on loading
the page. This then caused the visitor’s computer to be infected with malware.
Even well-known and widely trusted web sites were affected by this problem.
This document will illustrate some of the main techniques used in SQL
injection, then describe methods that can reduce the
effectiveness of such attacks. In addition to usual standard IT best practice,
such as logging and regular and prompt patching, the majority of SQL injection
vulnerabilities can be moderated through careful and robust programming.
Existing System:
SQL injection occurs when an SQL instruction
is entered in a field of an application or web page that a user can change in
an attempt for it to be passed to and executed by the back-end database. There
are a number of forms of SQL injection, which can be broadly separated into
input validation circumvention and blind SQL injection. While some attacks are
directed at a weakness in the database software, the majority of attacks seen
use a flaw in the interface to the database to (without permission) access,
add, or modify data, or to execute a command on the server itself. Clearly
there can be serious consequences when a malicious SQL injection attack
succeeds, affecting the confidentiality, integrity and availability of the data
and services it supports. The purpose of this document is to demonstrate why it
is necessary to code web pages and applications securely, giving examples of
SQL injection attacks and to summaries some ways that these systems can be secured.
Proposed System:
SQL injection is one of the main issues in
database security. It is a technique that may corrupt the information in the
database i.e. deletes or changes the full database or records or tables. To
exploit the database system, some vulnerable web applications are used by the attackers. These
attacks not only make the attacker to breach the security and steal the entire
content of the database but also, to make arbitrary changes to both the
database schema and the contents. The following section describes the attacks
with an example.
Generally the Authenticated users have
username and password such as,
Username: rahul
Password: 123
The SQL Query format will be as follows,
Select * from table where username='rahul' and pwd='123';
The above query then retrieves the needed
records from the database where username and pwd is
available in the database or it shows some error messages to the browsers. The
unauthorized users or the attackers inject the following SQL Injection in this
field:
Username: r hul
Password: 123
Then the dynamic SQL query constructed from
the above information is,
Select * from table where username=' r hul ' and pwd=123;
In this SQL statement, the actual username is
‘rahul’ which is modified as ' r hul’
by the attackers while generating the Query. This includes the image of ‘a’ in place of the character ‘a’. The attacker will now have
the capability of attacking the database by writing the injection code at the
inside location of the image (just as-image processing).
Scope and Objective:
A new approach for protecting Web
applications-An Image level Tainting, involves comparing the SQL statements
that includes the images viewed as characters in the user input with the Meta
strings library, to prevent them if found any and protecting the web
applications against SQL injection is discussed in this paper. This project includes the
strange idea of combining the Indication based method and the Inspection
Method. The main problem that occurs with web application security is the SQL
Injection, which gives the attackers unauthorized access to the database that
contains the Web applications. This leads to the cause of calamities in the Web
applications and this is very serious. On the other hand from the Inspection
based method point of view, it analyzes the transaction to find out the
malicious access. In Indication based method it uses an approach called Beschermen algorithm, not only to prevent the SQL Injection
attacks, but also reduces the time and space complexity.
LITERATURE SURVEY:
Boyd, Keromytis-2004
proposed SQLr and which uses instruction set
randomization of SQL statement to check SQL injection attack. It uses a proxy
to a append key to SQL keyword. A de-randomizing proxy then converts the
randomized query to proper SQL queries for the database. The key is not known
to the attacker, so the code injected by attacker is treated as undefined
keywords and expressions which cause runtime exceptions and the query is not
sent to database. The disadvantage of this system is its complex configuration
and the security of the key. If the key is exposed, attacker can formulate
queries for successful attack.
Russell A. McClure and Ingolf
H. Kruger-2005 proposed SQL DOM (SQL Domain Object Model): a set of classes
that are strongly-typed to a database schema. Instead of string manipulation,
these classes are used to generate SQL statements. We show how to extract the
SQL DOM automatically from an existing database schema, demonstrate its
applicability to solve the problems, and evaluate its performance.
Ke Wei et al.-2006
proposed a novel technique to defend against the attacks targeted at stored
procedures. This technique combines static application code analysis with
runtime validation to eliminate the occurrence of such attacks. In the static
part, we design a stored procedure parser, and for any SQL statement which
depends on user inputs, we use this parser to instrument the necessary
statements in order to compare the original SQL statement structure to that
including user inputs.
Recently, researchers have been exploring the
use of static analysis in conjunction with runtime validation to detect
instances of SQLIAs. In Buehrer and
Weide have proposed the use of parse trees to detect
malicious user input, which requires a developer to manually modify new and
existing code. As mentioned above, it is hard to predict the exact
structure of the intended SQL statement. Also there is an additional runtime
analysis overhead in terms of execution time which cannot be avoided due to the
sequential nature of the analysis techniques. The use of stored procedures
alone does not protect one against SQLIAs as is commonly assumed by most
developers, but appropriate use of parameters along with stored procedures is
necessary to achieve a minimal defense against such attacks .Various SQLIA
detection techniques for the application layer have been proposed in
literature, but none of them pay enough attention to SQLIA in stored
procedures.
ARCHITECHTURE DESIGN:
Architecture of the proposed technique
consists of three components. These are User Login Interface, SQL Injection
Protector for Authentication (SQLIPA) and User_account
table as shown in figure 7.
Here, User Login Interface is just the user
entry form for user name and password. User_account
is the table which stores user accounts data. Main component of the
architecture is SQL Injection Protector for Authentication. It is the component
which generates the hash values of user name and password for the first time
during the creation of user account and every time when an existing user wants
to login into database. Subcomponents of the SQL Injection Protector for
Authentication are “User Name Hash Value” and “Password Hash value”. User Name
Hash Value generates hash of user name and Password Hash value generates hash
value for password.
Contraints:
A prototype named SQL Injection Protector for
Authentication (SQLIPA) has been developed for evaluating the proposed
technique. Two store procedures with name Create_user_account
and User_authentication have been used. Create_user_account store procedure is
used when a new user
account is created for the first time. Reciting module includes the Meta
strings library which comprises the predefined keywords and is updated with new
type of information in terms of coordinates of the images, their pixels
information, color resolution and the details on type of images. If both
comparative module and inspection module has satisfied, it provides the
complete transaction.
Assumptions and
Dependencies:
Authorization
Diversions (SQL Manipulation)
This attack allows the attacker access the
total information in the database [15]. The example of this attack is discussed
in the above section.
Exploiting
Insert:
The Web Sites like Banking, when
registration, it allows the user to feed inputs and store it. INSERT statement
allows the user input to store in the back end. The misuse of INSERT statements
by the attacker results in many rows in the database with corrupt data.
Exploiting
SELECT:
SQL injection is not only a straight forward
attack but also it has some background tricky attack is present. Most of the
time attackers would see some error message and will have to reverse engineer
their queries..Direct Vs Informative (SQL
manipulation) – Both Direct and informative are the types of SQL Injection
attacks in SQL manipulation. In direct attack, the input data become part of
the SQL statement formed by the application. Attacker has to add image in place
of a character in a way that image is also visible as character which
manipulates the SQL statement. The error message has been returned if the
injection was successful.
Exploiting
System Stored Procedures (Function Call):
Database uses stored procedures to perform
database Administrative operations. Attacker uses stored procedures to corrupt
the database system and it’s a most harmful attacks.
SELECT usrid,
details, username from user where username like ‘r hul’;
to execmaster.dbo.xp_cmdshell "dir.
Reciting
Module:
Reciting module includes the Meta strings
library which comprises the predefined keywords and is updated with new type of
information in terms of coordinates of the images, their pixels information,
color resolution and the details on type of images
Comparative
Module:
In Comparative module, it gets an input from
the web application and it compares the statement with the Meta strings library
included in the Reciting Module, if founds any error message it attempts to
block the query.
E-R Diagram:
Every time a client request comes in, the
runtime finite state automata of the different SQL queries in the SQL-graph are
validated. A Verification Table (VT) is then computed for the different SQL
queries indicating whether it can be allowed to pass through or whether it
should be dropped before being sent to the database. Now verifying the finite
state automata for all the queries in the SQL-graph can be computationally
intensive and can be expensive in terms of the runtime processing time for the
stored procedure. The concept of the directed dependency in the SQL-graph is
used to reduce the total runtime overhead.
UML Diagram
Class Diagram
The on waiting list association
is unidirectional because there isn’t yet a need for collaboration in both
directions. The enrolled in association between the Student
and Enrollment classes is also uni-directional
for similar reasons. For this association it appears student objects know what
enrollment records they are involved with, recording the seminars they have
taken in the past, as well as the seminars in which they are currently
involved. The instructs association between the Professor class
and the Seminar class is bidirectional because professor objects know
what seminars they instruct and seminar objects know who instruct them.
When I’m conceptual modeling my style is to
name attributes and methods using the formats Attribute Name and Method
Name, respectively. Following a consistent and sensible naming
convention helps to make your diagrams readable, an important benefit of AM’s Apply
Modeling Standards practice. Also notice in Figure 2 how I haven’t modeled
the visibility of the attributes and methods to any great extent. Visibility is
an important issue during design but, for now, it can be ignored.
Use Case Diagram
Sequence Diagram
Activity Diagram
MODULE DESIGN:
Reciting module includes the Meta strings
library which comprises the predefined keywords and is updated with new type of
information in terms of coordinates of the images, their pixels information,
color resolution and the details on type of images (extension files like .jpg
etc). If both comparative module and inspection module has satisfied, it
provides the complete transaction. The following section outlines each module's
work in detail.
Reciting
Module:
Reciting module includes the Meta strings
library which comprises the predefined keywords and is updated with new type of
information in terms of coordinates of the images, their pixels information,
color resolution and the details on type of images (extension files like .jpg
etc).
Comparative
Module:
In Comparitive
module, it gets an input from the web application and it compares the statement
with the Meta strings library included in the Reciting Module, if founds any
error message it attempts to block the query. The time complexity of this
algorithm is O(nm) and space complexity is O(min(nm)).
Beschermen
Algorithm:
Beschermen algorithm is
generally applicable algorithm for finding an optimal sequence alignment. Let,
The Statement generated from the Web application is =Q The
Character of the Statement is =C, The Meta String Library = M .The Pixel Size
of the statement= X The Original Statement included in the Meta String library=
S.
Hence, The Pixel size of the generated
Statement = Q(X),
The Pixel size of the original String in Meta
Strings Library = M(S(X)).
SQL Injection code
Select * from table where username=' r hul ' and pwd=123;
DATABASE
DESIGN:
This is a very important issue to consider
when you're using form/url variables in databases.. I get the feeling that there are several people that
aren't aware of this when they develop their apps. For
example, if you define something expecting an integer,
and a user manually puts in
99999999999999999999999999999999999999999999999999999999999999999
9999999999999999999999999999999999999999999999999999999999 it can cause
unexpected results.
Strings - if it’s a value from a list box or
pull down menu, error check for those values in the script...
if anything else, take necessary action. If it's a string the user has to put
in, check if the first chars are: ' or " or ; - (If the user is expected
to put in a their name, a number, a name, there should be no reason why they
would be putting fields/chars that are part of SQL statements.
Also make sure you always replace all <>"& with their html
entities. When accepting variables from a form/url
make sure you have a function that always replaces single apostrophes with
double apostrophes.
select * from customers
where customerid = 'ALFKI'
"ALFKI" in this case is dynamically
inserted through whatever script language into the SQL
statement. There's nothing wrong with this statement. Now, what if the user
inserts the following?
ALFKI';select * from customers - -He enters the above as
you see it. With the apostrophes, semicolon, asterisk, and two dashes at the
end. This statement will append another SQL statement to the
previous. So now you will get a list of customers where customerid
= ALFKI and another list of everyone under customers.
The first apostrophe you see in the SQL statement in figure 2
closes the statement in figure 1, and appends the extra select statement. The
two dashes at the end of figure 1 are to comment out (in SQL
Server) the apostrophe in figure 1's last dash. So your original SQL
statement (figure 1) will now be executed as the following:
Select * from customer
where customerid = 'ALFKI';
select * from customers--'
Replacing single apostrophes with double
apostrophes can be beneficial in this case. Of course the person doing the
injections won't know the table names, but however will get the page to crash.
INTERFACE
DESIGN:
The cost model uses (a)-(c) to compute and
associate the following information in a bottom-up fashion for operators in a
plan: (1) The size of the data stream represented by the output of Furthermore,
in the System R optimizer, two plans are compared only if they represent the
same expression as well as have the same interesting order. Despite the
elegance of the System-R approach, the framework cannot be easily extended to
incorporate other logical transformations (beyond join ordering) that expand
the search space. It also determines the estimated size of the data stream for
output of every operator in the plan
CONCLUSION:
Most web applications employ a
middleware technology (scripting engine) designed to request information from a
relational database in SQL parlance. SQL injection is a common techniques hackers employ to attack underlying databases.
These attacks reshape the SQL queries, thus altering the behavior of the
program for the benefit of the hacker. In this paper, we present a fully
automated technique for detecting, preventing and reporting SQLIA incidents in
stored procedures. The technique abstracts the intended
FUTURE
ENHANCEMENT:
We believe that the SQLDOM4J
solution, which was developed in the scope of a master thesis research project,
could significantly benefit from improvements to its accuracy and performance;
here are the main ones that we have identified. Column lengths (e.g. for varchar fields) could be stored in the DB class (as names
and data types are) allowing the solution to perform bounds validation for
input data and therefore increase its protection level and overall accuracy.
The main source of overhead is
the use of the underlying DBMS-driven Prepared Statement interface and we
believe that its use within our API could be limited while still offering a
similar level of protection. For instance, accuracy tests have shown that type
violations are successfully detected by the API. Hence, SQL queries which do
not use variable text values could be built without the use of Prepared
Statements, whose added value mainly pertains to text field protection.
REFERENCES:
1 Andrews, M.: Guest Editor's Introduction: The
State of Web Security. IEEE Security and Privacy, 4, 4, 14--15 (2006)
2 Janot, E.:
SQLDOM4J: Preventing SQL Injections in Object-Oriented Applications. Master
thesis, Concordia University College of Alberta (2008),
http://waziboo.com/thesis
3 McClure, R., Krüger,
I.: SQL DOM: Compile Time Checking of Dynamic SQL Statements. In: 27th IEEE
International Conference on Software Engineering, pp. 88--96. IEEE Press, New
York (2005)
4 Power, R.: 2002 CSI/FBI Computer Crime and
Security Survey. Computer Security Issues & Trends, 8, 1, 1--22 (2002)
5 Boyd, S., Keromytis,
A.: SQLrand: Preventing SQL Injection Attacks. In:
Nagel, W.E., Walter, W.V., Lehner, W. (eds.) ACNS
2004. LNCS, vol. 3089, pp. 292--304. Springer,
Heidelberg (2004)
6. http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt
7. http://oracle.com/technology/products/ias/toplink/doc/
11110/devguide/ qrybas.htm# CIHEBF
8. http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt
Received on 22.08.2014 Accepted
on 20.09.2014
©A&V
Publications all right reserved
Research J. Engineering and Tech. 5(3): July-Sept.
2014 page 135-143